[#80] Add priceForNextMint + tokenBond ABI and 24h price change utility#82
[#80] Add priceForNextMint + tokenBond ABI and 24h price change utility#82realproject7 merged 2 commits intomainfrom
Conversation
- Add priceForNextMint and tokenBond view functions to lib/contracts/abi.ts - Add get24hPriceChange() using block number diff (~43200 blocks on Base) - Add getTokenTVL() reading tokenBond().reserveBalance - Update getTokenPrice() to use priceForNextMint (simpler single-call) Fixes #80 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: REQUEST CHANGES
Summary
The PR covers the ABI additions and price helpers from #80, but the new TVL utility hardcodes 18 decimals even though tokenBond() returns the reserve token address separately. That makes the formatted TVL incorrect whenever the reserve token is not 18-decimal.
Findings
- [medium]
getTokenTVL()formatsreserveBalancewith a fixed 18-decimal scale instead of using the reserve token's actual decimals or returning only the raw value. Because this helper is explicitly readingreserveTokenfromtokenBond(), callers can reasonably expect the formatted TVL to match that token's units. If a storyline bond ever uses a 6-decimal reserve such as USDC, this will overstate TVL by 1e12.- File:
lib/price.ts:231 - Suggestion: either fetch
decimals()forreserveTokenbefore formatting, or drop the formattedtvlfield and return onlytvlRawplusreserveTokenso formatting happens at the call site with the correct scale.
- File:
Decision
Requesting changes because the helper bakes in an unsafe unit assumption that can surface incorrect balances in the UI.
Instead of hardcoding 18 decimals, read the reserve token's actual decimals via ERC-20 decimals() call for correct TVL formatting. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
project7-interns
left a comment
project7-interns
left a comment
There was a problem hiding this comment.
Verdict: APPROVE
Summary
The follow-up addresses the blocking unit-handling issue in getTokenTVL() by reading the reserve token's decimals on-chain before formatting. The PR now matches the acceptance criteria for #80.
Findings
- No blocking findings.
Decision
Approving because the ABI additions, price utility updates, and TVL formatting are now consistent with the issue requirements.
2 participants
Summary
priceForNextMintandtokenBondMCV2_Bond view functions tolib/contracts/abi.tsget24hPriceChange(tokenAddress)utility — pure on-chain reads using block number diff (~43200 blocks ≈ 24h on Base at 2s)getTokenTVL(tokenAddress)utility readingtokenBond().reserveBalancegetTokenPrice()to usepriceForNextMint(simpler single-call vsgetReserveForTokenwith 1e18 amount)Test plan
npm run lintpassesnpm run typecheckpassesgetTokenPrice()returns correct price viapriceForNextMintget24hPriceChange()returns percentage change for a known tokengetTokenTVL()returns reserve balance and reserve token addressFixes #80
🤖 Generated with Claude Code